1. Field of the Invention
This invention relates generally to computing technology and more particularly concerns the testing of Application Programming Interfaces (APIs)
2. Description of the Related Art
Developing tests for API testing of a complex system is by itself a formidable task. This task is further compounded by the requirement for the API test suite to support many different operating systems. Typically, separate test suites need to be maintained for each operating system tested. In addition, separate test development environments are needed for each operating system under which tests need to be created. Also, the porting task for moving the complex test engine and user interface between the operating systems is a significant development task.
FIG. 1A shows a typical API testing system. In one example, the API testing system includes a storage 12 connected to a target 14 that is interconnected with both an initiator 18 and a third party remote 20 through a switch 16. The initiator 18 typically communicates with the target 14 which has the storage 12 associated with it. The switch 16 is generally a network device, such as a router or bridge. Third party companies generally need to manage initiators remotely through the third party remote 20 that uses their own third party graphic user interface (GUI). The API usually is defined by the maker of the initiator 18. Different APIs are generally written for different systems.
The third party needs to know the API for the initiator 18. The API is typically provided by the makers of the initiator 18 for the particular system. Third party remotes 20 utilized to manage initiators typically need to know how to communicate with the initiators. Consequently, the third party remote needs to know the API of the initiator 18 and the operating system. If code must be ported to the third party remote to test the API on the initiator 18, then this takes a large amount of time and effort.
FIG. 1B illustrates typical systems under test. In a typical system under test (SUT) such as SUT-1 40 through SUT-N 44, each of the systems under test have a test code such as test code-1 42 through test code-N 46. Generally each of the SUTs has a particular test code, which a user would have to install on the system. Consequently, API testing code typically must be ported to different systems to test whether each of the APIs are working. As a result, APIs must be manually ported and tested on the local machine. As the number of SUTs grows, the number of test codes grows. Therefore, to test each of the SUTs, extensive time is generally necessary to port new code to the new system.
Therefore, there is a need for an initiator-target system that enables centralized console API testing.